This invention relates to the field of computer systems. More particularly, an interface is provided for coupling an input/output device to any of multiple types of host buses.
Many computer system devices or components, such as network interface units or adapters, storage devices, peripheral devices, and so on, initiate input/output operations using DMA (Direct Memory Access) over a host computer's system bus. Split transactions are often enabled to allow improved access to the bus by bus clients.
When split transactions are enabled for read operations, a single read transaction from the device generates two separate system bus transactions: one to issue the read request, and one to return the requested data. In between the two transactions, the system bus is released for use by other devices. If split transactions are not enabled for read operations, the system bus is not relinquished by a component that issued a read request until the requested data were returned.
When split transactions are enabled for write operations, a device that issues a non-posted write operation releases the system bus once the operation has been transferred to the DMA bridge. If split transactions are not enabled for writes, the system bus is not released until acknowledgement of completion of the non-posted write.
Characteristics of read and non-posted write transactions differ, depending on the architecture of the computer system. For example, different types of system buses, such as PCIe (Peripheral Component Interconnect Express) and HT (Hyper Transport), allow data transfers of different maximum sizes, may involve different expected or allowable latencies, etc. Some systems do not even allow or support non-posted writes.
Because each system bus transaction is relatively low-level, usually involving the transfer of a small amount of data, one read operation (e.g., to retrieve data to be transmitted in one packet over a network) or one write operation (e.g., to write the contents of one packet received from a network) may require a number of system bus transactions. If the device is only capable of tracking the statuses of a limited number of system bus transactions, the device may stall whenever the total number of transactions in-flight reaches that number.
Traditionally, a device configured to generate read or write transactions over a system bus has contained built-in logic for detecting and possibly handling errors that occur during the transactions. Typically, different versions of the device would be designed and produced for each type of system bus. Attempting to configure the device to work with any of multiple different system buses would require the device to include logic capable of tracking transactions for each type of system bus, and would make the design too complex and/or inefficient.
In addition, verification strategies for verifying correct operation of an input/output device have generally be tightly coupled to the design of the device. For example, to verify a complex ASIC, each module of the ASIC is usually verified separately with a testbench tailored to the module. Any change to a module would require a corresponding change to the testbench. And, the correctness of the verification is highly dependent on the accurate modeling of the behavior of other modules that interact with the module being tested.
Further, complex chips such as ASICs and input/output interfaces are typically designed for use in a specific architecture (e.g., with one type of host bus). Because such a chip connects only to a single bus, a simplified verification strategy is often implemented to verify the chip with that architecture. Even if such a chip could be designed for use with multiple different architectures or host buses, conventional wisdom would call for a separate verification strategy for each architecture. This would significantly increase the complexity and require substantial time to verify the chip.